Hey

Don't suppose you could add a test showing this problem and verifying the fix. We are trying to get some improved coverage lately because there are some rather large changes in the works (internally) and we don't want to regress anything.

Hi Jake, I'm going to try to look at this today.
I haven't been able to reproduce by creating a new repository in the test as the issue seems to only occur when tracking branches exist. so I'll create a one on git to use in the test that mimics the behaviour.

If you need a hand with the tests, like how to create tracking branches on the fly using libgit2 then i'm sure either myself or @nulltoken could help out.

Hi Jake

I've created a repository here https://github.com/grufffta/GitVersionTest that reproduces the issue for the test. I did have a brief look at using lib2git, but, if you have an example on how to create the tracking branches then I will happily switch it over as that was what was holding me back.

Here are some libgit2sharp tests which should give you the components to do this:

https://github.com/libgit2/libgit2sharp/blob/vNext/LibGit2Sharp.Tests/BranchFixture.cs#L294
https://github.com/libgit2/libgit2sharp/blob/vNext/LibGit2Sharp.Tests/BranchFixture.cs#L358
https://github.com/libgit2/libgit2sharp/blob/vNext/LibGit2Sharp.Tests/RemoteFixture.cs#L62

Then the test could look something like:

using (var remote = new EmptyRepositoryFixture(new Config()))
using (var local= new EmptyRepositoryFixture(new Config()))
{
    local.Network.Remotes.Add(remote);
    remote.MakeACommit();

    etc..

Appreciate you looking into this. Also it would be good to use Assert.Throws or Should.Throw rather than [ExpectedException]

I also like the idea of the remote branch fixture. Would be good to create a nice pattern for this sort of test